The invention relates to a technology for detecting a possibility of a deadlock beforehand without actually running a deadlock detection object program.
A technology has hitherto been proposed as a deadlock detection method, wherein a deadlock is detected by executing a procedure (process steps) as a deadlock detection object, or by analyzing a data access sequence obtained as a simulation.
FIG. 17 shows an example of this deadlock detection method. FIG. 17 shows that a history (a SQL history in FIG. 17) of an on-execution application having accessed a database is recorded by a history extractor (an SQL history extractor in FIG. 17), a deadlock detector executes a predetermined process on the basis of this access history, and a result of detecting the deadlock is thereby outputted (refer to, e.g., Patent document 1 and Patent document 2, etc.).
[Patent document 1] Japanese Patent Application Laid-Open Publication No.2000-222228
[Patent document 2] Japanese Patent Application Laid-Open Publication No.10-49389
According to the conventional deadlock detection method, however, the detection of the deadlock requires an actual execution of a deadlock detection object program. Hence, there arise the following problems.
(1) None of deadlocks other than the deadlock with respect to only the actually operated element can be detected. In other words, it is difficult to prove that the deadlocks with respect to all the cases (all the process routes) have been detected (all-inclusive detection). Especially in the case of authenticating a program at a multi-access time, it is, as a matter of fact, almost impossible to check all the possibilities.
(2) The check is performed after the program has already been created, and hence there increases a cost for modifying the program in order to obviate the deadlock (the modifying cost is 10 times to 100 times as large as the modification at a design stage).
(3) In the case of developing respective pieces of job logic by sharing, there is a scatter in implementation of the data access sequence, depending on a person in charge, and hence the deadlock might occur. This problem can not, however, be obviated by the method of checking after the program has been created.
A first object of the invention lies in detecting a deadlock possibility beforehand without actually running a program as a deadlock detection object. Further, a second object of the invention lies in enabling a user to adopt a measure, etc. for avoiding the deadlock possibility by notifying the user of the measure, etc. for avoiding the thus-detected deadlock possibility.